﻿[ QUESTO FILE E’ IN FORMATO PDF, PERCHE’, PER QUALCHE MOTIVO, IL SISTEMA DI GESIONE DEL MATERIALE DIDATTICO DI QUESTO SITO NON ACCETTA IL CONTENUTO DI QEUSTO FILE, SE LASCIATO IN FORMATO TESTO ]


QUALITA' DEL CODICE

Per riprendere l'argomento, potete partire dalle mie brevi note:
http://algogroup.unimore.it/people/paolo/courses/programmazione_I/edizione_1617/materiale_1617/lezioni/Lez_12-Ingegneria_del_codice.pdf

Per poi approfondire qui:
https://www.kernel.org/doc/html/latest/process/coding-style.html

---------------------------

CREAZIONE COMMIT

Prima riga:
<dove_agisce_la_modifica>: <cosa fa la modifica>

block, bfq-mq: boost performance by 800%

-usate verbi, che descrivono l'azione del commit, ad esempio non va bene:
block, bfq: performance boost by 800%

In ogni caso, questo esempio di titolo può essere troppo generico. Meglio un titolo più tecnico, che spiega esattamente cosa fa il commit. Ad esempio:

block, bfq: boost performance by avoiding device idling

Lasciare una riga vuota dopo titolo

Corpo del commit
- contesto del problema
- motivazione del commit
- miglioramento/correzione apportata dal commit

A parte queste poche note, studiatevi con molto cura il documento:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

---------------------------

CONTROLLO DEL COMMIT

./scripts/checkpatch.pl -g <hash commit>
oppure, se volete controllare una patch
./scripts/checkpatch.pl <file contenente la patch>

-----------------------------

QUANDO SOTTOMETTERE PATCH PER IL KERNEL

Da email di Jens Axboe, incavolato con me perché avevo tirato la corda per l'ennesima volta:

Patches look fine to me. You are in fact several weeks late for 4.19, I
need to have anything that's going in to 4.19 by 4.18-rc6 or 4.18-rc7 time
(depending on whether we have an -rc8 or not). This is to ensure that it
gets plenty of time in linux-next as well. I've queued up patches this
time (since they were small), but please send them in in due time next
time.

-----------------------------

SOTTOMISSIONE COMMIT

1. Creazione patch
git format-patch --subject-prefix="<prefisso>" <hash commit padre>

Esempio:
git format-patch --subject-prefix="PATCH" HEAD~

Spesso è conveniente associare una cover letter alla patch:
git format-patch --cover-letter --subject-prefix="<prefisso>" <hash commit padre>
git genererà una cover letter, in cui dovrete solo aggiungere subject e corpo della lettera

2. Controllo destinatari a cui spedire

./scripts/get_maintainer.pl <patch>

Inoltre spedite a tutte le persone che pensate possano essere interessate

2. Spedizione patch
<ATTENZIONE, GIT-SEND-EMAIL E' UN PACCHETTO A PARTE: git-email>

git send-email <cover letter, se c'è> <patch 1> <patch 2> ... -to <indirizzo email> -to <indirizzo email> ... -cc <indirizzo email> -cc <indirizzo email>

Esempio:
git send-email 00* -to "Jens Axboe <axboe@kernel.dk>" -cc linux-block@vger.kernel.org -cc linux-kernel@vger.kernel.org -cc ulf.hansson@linaro.org -cc broonie@kernel.org -cc linus.walleij@linaro.org -cc lucmiccio@gmail.com

-------------------------------

CONFIGURAZIONE GIT SEND-EMAIL

Configurare git send-email, affinché spedisca correttamente delle email, può non essere banale. Eccovi un elenco di configurazioni appropriate, per i provider di posta più comuni.

@outlook.it:
sendemail.smtpencryption = tls (oppure ssl)
sendemail.smtpserver = smtp.live.com (oppure provate smtp-mail.outlook.com)
sendemail.serverport = 587 (oppure 25)
sendemail.smtpuser=<indirizzo posta>

@gmail:
sendemail.smtpencryption=ssl
sendemail.smtpserver=smtp.gmail.com
sendemail.smtpserverport=465
sendemail.smtpuser=<indirizzo posta>

@aruba
sendemail.smtpencryption = ssl
sendemail.smtpserver = smtps.aruba.it
sendemail.smtpuser = <indirizzo posta>
sendemail.smtpserverport = 465

Se ancora non funziona, bisogna abilitare app meno sicure su gmail, come spiegato qui:

https://support.google.com/accounts/answer/6010255?hl=it

In particolare, selezionare il link di "opzione 2":
sezione "App meno sicure" di Account personale.

-------------------------------

NOTE SU PATCH INLINE

git send-email crea patch cosiddette inline, ossia email in cui la patch non è in un allegato, ma è l'email stessa. Questa soluzione è perfetta per la revisione, perché si riescono ad inserire poi commenti inline nella propria revisione, senza alcuna difficoltà.

E' però un formato che può dare problemi nel caso proviate ad applicare una patch a partire da un'email, ossia a salvare l'email e poi applicarla come patch. Infatti, i client di posta spesso si divertono a modificare in modi sottili la formattazione delle email che ricevono, corrompendo di fatto la patch.

Se vi si verificano questi problemi su patch spedite pubblicamente sulle mailing list del kernel, una soluzione che funziona è
https://patchwork.kernel.org/
Si tratta di un archivio in cui vengono inserite automaticamente tutte le patch che vengono spedite su tali mailing list. Cercate il messaggio contenente la patch che vi interessa, quindi scaricate la patch direttamente da patchwork.

Se invece si tratta di una patch speditavi privatamente da un collega o simili, la soluzione più semplice è chiedere al collega di spedire la patch come allegato compresso. Con questa soluzione, si impedisce al client di posta di effettuare qualsiasi corruzione della patch. Attenzione che non basta che sia semplicemente un allegato, perché, se l'allegato è un file di testo, i client spesso corrompono il testo contenuto nell'allegato.

---------------------------------

CONSIGLI SU SOLLECITO DOPO LA SOTTOMISSIONE DI UNA PATCH

Se il maintainer non risponde, e non abbiamo elementi specifici per decidere quando sollecitarlo, di norma due o tre settimane possono essere un tempo ragionevole.

In quanto al messaggio da usare per un sollecito, di norma conviene usare il massimo del tatto e della gentilezza, per tanti motivi. Inoltre tipicamente è meglio essere informali. Quindi una domanda del tipo "per caso hai avuto modo di guardarci?" può essere una buona idea.

Ossia, in inglese:
Hi Jens,
have you had time to look into this?

Thanks,
<nome>

può essere sufficiente. Dati questi consigli, usate però il linguaggio e le formula con cui vi sentite a vostro agio, perché alla fin fine gli autori dell'email sarete voi!

-----------------------------------

INTERAZIONE CON LA COMUNITA'

Alcuni degli spunti migliori direi che siano riassunti in questo articolo, apparentemente relativo ad un argomento diverso:

https://heleo.com/facts-dont-change-peoples-minds-heres/16242/
